So.. I think we could make this Option<PreviewMode> too but I'm not entirely sure how to make that play nicely with the JsonSchema. I'm also not sure if we want preview = enabled | disabled or preview = true | false for users.

I quickly looked into this but don't see a good solution for it other than implementing Serialize, Deserialize and JsonSchema manually on PreviewMode if we want preview = true | false (preview = enabled | disabled) should work out of the box.

Thanks! I'm happy to leave it as-is then

This always reminds me of @charliermarsh's tweet about how high-performance code looks like 😆

This type being inside of the ruff crate means that we can't use it in the formatter, or any other crate (e.g. consider we need to gate some semantic model change)

Hm it seems wrong to put it elsewhere right now since there's a dedicated settings/types.rs module. This is a good callout though, we should probably have a ruff_settings crate so we can share with the formatter?

I think we can just move the PreviewMode because the type itself isn't specific to settings.

A ruff_settings crate isn't straightforward because the settings depend on the rules. So you would need to make the formatter depend on ruff.

I consider (at least most of what is in settings) settings as the linter-specific settings. The formatter has its own resolved settings that only contain the formatter settings. Most of this already exists with PyFormatOptions, although we probably want to add a few more settings.

What I have in mind is:

• each tool has its own resolved settings object
• Configuration is the unified configuration from which the workspace derives the tool Settings

Where would you expect it to go?

I don't know 😅

It would need to be some rather low-level crate that other crates can depend on without pulling in too many dependencies.

The alternative is to duplicate the enum in project where it is needed. I don't really mind that (e.g. the Linter has LineLength and the formatter has a very similar LineWidth option type)

Alright let's consider this TBD when preview support is added to the formatter

Another way we could take is that PreviewMode remains in the configuration only and setting it to true or false changes individual settings in the tool-specific settings. Each tool can then decide whether it uses feature-specific flags or a single preview flag. For example, the formatter can either:

• Have a single preview setting that is set to enabled/disabled based on the preview mode
• Or an experimental-string-handling and potentially other settings that configure a specific preview feature. Setting preview=true would enable/disable all of them at once.

The benefit of feature specific flags is that individual features can be moved out of preview mode (and makes it easier to find all places where the check now needs to be removed)